None
Use this command to transfer IP resilient sets to the secondary controller when the primary controller needs to be rebooted.
Enter this command on the primary controller.
The primary controller waits until each IP resilient set is IDLE before it passes control over to the secondary controller. To avoid overloading the secondary controller, the IP sets are transferred in batches of five IP sets. The batches are sent over to the secondary controller at intervals of 0.5 seconds.
Enter the HST STATUS_HANDOFF command to check the transfer status of the IP resilient sets.
You must enter this command on the primary controller.
You will see an error message if you enter this command on the secondary controller.
If the Secondary ICP is unreachable, the IP resilient sets will remain on the Primary ICP until system reboot or until the Secondary ICP is in service again.
You can cancel a HST COURTESY_HANDOFF that is in progress by entering the HST CANCEL_HANDOFF command.
If an IP resilient set has already failed over to the secondary controller, it will remain there until the Courtesy Handoff is cancelled or until the primary controller is rebooted. After the cancel or reboot, the IP resilient sets will fail back normally.
NOTES
The HST COURTESY_HANDOFF command will have no effect on non-resilient sets. They will be out of service during ICP upgrades, reboots or failures.
The HST COURTESY_HANDOFF command will not fail over groups such as Personal Ring Groups, Ring Groups, Resilient ACD, or Resilient Hunt Groups.
Sending COURTESY_HANDOFF Msg...
For the status type HST STATUS_HANDOFF
If you enter the Courtesy Handoff command twice, the system response is
COURTESY_HANDOFF already called